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(57) Methods and systenns are provided for control- 
ling the scope of delegation of authentication credentials 
within a networl< environnnent. A server is configured to 
provide a trusted third-party with a ticket authenticating 
the server, information about a target service that a serv- 
er seeks to access on behalf of the client, and a service 



ticket associated with the client. This service ticket may 
be provided by the client or may be a previously granted 
service ticket granted to the server for itself in the name 
of the client. The trusted third-party grants a new service 
ticket to access the target service to the server, in the 
client's name, if such delegation is permitted according 
to delegation constraints associated with the client. 
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Description 
TECHNICAL FIELD 

[0001] This invention relates generally to connputer 
access control, and nnore particularly to nnethods and 
systems for controlling tlie scope of delegation of au- 
thentication credentials. 

BACKGROUND 

[0002] Access control is parannount to computer se- 
curity. To protect the integrity of computer systems and 
the confidentiality of important data, various access con- 
trol schemes have been implemented to prevent unau- 
thorized users and malicious attackers from gaining ac- 
cess to computer resources. 

[0003] To ensure the comprehensiveness of compu- 
ter security, access control is often implemented on var- 
ious levels. For instance, on the level of one computer, 
a user is typically required to go through a logon proce- 
dure in which the computer determines whetherthe user 
is authorized to use the computer. In addition, on the 
level of a computer network, a user is commonly re- 
quired to go through a user-authentication process for 
purposes of controlling the user's access to various net- 
work services. Even after a network access control serv- 
er has authenticated the user, the user may still have to 
request a permit for a specific server in order to access 
that service. Various schemes based on different proto- 
cols, such as the Kerberos 5 protocol, have been pro- 
posed and implemented for controlling network access 
control by means of user authentication. 
[0004] Generally, the user logon for a computer and 
the user authentication for network access control are 
two separate procedures. Nevertheless, to minimize the 
burden on a user in dealing with the different access 
control schemes, the user logon and the user authenti- 
cation for network access are sometimes performed to- 
gether. For example, in the case where the user authen- 
tication is implemented under the Kerberos protocol, 
when the user logs on the computer, the computer may 
also initiate a Kerberos authentication process. In the 
authentication process, the computer contacts a Ker- 
beros Key Distribution Center (KDC) to first obtain a tick- 
et-granting ticket (TGT) for the user. The computer can 
then use the TGT to obtain from the KDC, a session tick- 
et for itself. 

[0005] As networks have evolved, there has been a 
trend to have multiple tiers of server/service computers 
arranged to handle client computer requests. A simple 
example is a client computer making a request to a 
World Wide Web website via the Internet. Here, there 
may be a front-end web server that handles the format- 
ting and associated business rules of the request, and 
a back-end server that manages a database forthe web- 
site. For additional security, the web site may be config- 
ured such that an authentication protocol f onwards (or 



delegates) credentials, such as, e.g., the user's TGT, 
and/or possibly other information from the front-end 
server to a back-end server. This practice is becoming 
increasingly common in many websites, and/or other 
5 multiple-tiered networks. 

[0006] Thus, any server/computer in possession of 
the user's TGT and associated authenticator can re- 
quest tickets on behalf of the user/client from the KDC. 
This capability is currently used to provide forwarded 
10 ticket delegation. Unfortunately, such delegation to a 
server is essentially unconstrained for the life of the 
TGT. Consequently, there is a need for improved meth- 
ods and systems that support delegation of authentica- 
tion credentials in complex network configurations, but 
15 in a more constrained manner. 

SUMMARY 

[0007] Improved methods and systems are provided 
20 herein, which provide constrained delegation of authen- 
tication credentials. 

[0008] The above stated needs and others are met, 
for example, by a method that includes identifying a tar- 
get service to which access is sought on behalf of a cli- 

25 ent, and causing a server to request a new service cre- 
dential, for use by the server, from a trusted third-party. 
To accomplish this, the server provides the trusted third- 
party with a credential authenticating the server, infor- 
mation about the target service, and a service credential 

30 previously obtained by the client, or by the server on 
behalf of the client. Here, the new service credential is 
granted in the identity of the client rather than that of the 
server, but can only be used by the serverto gain access 
to the target service. 

35 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] A more complete understanding of the various 

methods and systems of the present invention may be 
40 had by reference to the following detailed description 
when taken in conjunction with the accompanying draw- 
ings wherein: 

Fig. 1 is a block diagram generally illustrating an ex- 
45 emplary computer system on which the present in- 
vention may be implemented. 
Fig. 2 is a block diagram depicting a service-for-us- 
er-to-proxy (S4U2proxy) process performed within 
a client-server environment, in accordance with cer- 
50 tain exemplary implementations of the present in- 
vention. 

Fig. 3A is a block diagram depicting a service-for- 
user-to-self (S4U2self) process performed within a 
client-server environment, in accordance with cer- 
55 tain exemplary implementations of the present in- 
vention. 

Fig. 3B is a block diagram depicting a service-for- 
user-to-self (S4U2self) process performed within a 
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client-server environment, in accordance with cer- 
tain furtlier exenriplary innplennentations of the 
present invention. 

Fig. 4 is an illustrative diagrann depicting selected 

portions of a message format suitable for use with 
certain implementations of the present invention. 

DETAILED DESCRIPTION 

[001 0] Turning to the drawings, wherein like reference 
numerals refer to like elements, the invention is illustrat- 
ed as being implemented in a suitable computing envi- 
ronment. Although not required, the invention will be de- 
scribed in the general context of computer-executable 
instructions, such as program modules, being executed 
by a personal computer. Generally, program modules 
include routines, programs, objects, components, data 
structures, etc. that perform particular tasks or imple- 
ment particular abstract data types. Moreover, those 
skilled in the art will appreciate that the invention may 
be practiced with other computer system configurations, 
including hand-held devices, multi-processor systems, 
microprocessor based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be prac- 
ticed in distributed computing environments where 
tasks are performed by remote processing devices that 
are linked through a communications network. In a dis- 
tributed computing environment, program modules may 
be located in both local and remote memory storage de- 
vices. 

[0011] Fig.1 illustrates an example of a suitable com- 
puting environment 120 on which the subsequently de- 
scribed methods and systems may be implemented. 
[0012] Exemplary computing environment 120 is only 
one example of a suitable computing environment and 
is not intended to suggest any limitation as to the scope 
of use or functionality of the improved methods and sys- 
tems described herein. Neither should computing envi- 
ronment 120 be interpreted as having any dependency 
or requirement relating to any one or combination of 
components illustrated in computing environment 120. 
[0013] The improved methods and systems herein 
are operational with numerous other general purpose or 
special purpose computing system environments or 
configurations. Examples of well known computing sys- 
tems, environments, and/or configurations that may be 
suitable include, but are not limited to, personal comput- 
ers, server computers, thin clients, thick clients, hand- 
held or laptop devices, multiprocessor systems, micro- 
processor-based systems, set top boxes, programma- 
ble consumer electronics, network PCs, minicomputers, 
mainframe computers, distributed computing environ- 
ments that include any of the above systems or devices, 
and the like. 

[0014] As shown in Fig. 1, computing environment 
1 20 includes a general-purpose computing device in the 
form of a computer 130. The components of computer 



1 30 may include one or more processors or processing 
units 132, a system memory 134, and a bus 136 that 
couples various system components including system 
memory 134 to processor 132. 

5 [001 5] Bus 1 36 represents one or more of any of sev- 
eral types of bus structures, including a memory bus or 
memory controller, a peripheral bus, an accelerated 
graphics port, and a processor or local bus using any of 
a variety of bus architectures. By way of example, and 

10 not limitation, such architectures include Industry Stand- 
ard Architecture (ISA) bus, Micro Channel Architecture 
(MCA) bus. Enhanced ISA (EISA) bus. Video Electron- 
ics Standards Association (VESA) local bus, and Pe- 
ripheral Component Interconnects (PCI) bus also 

f5 known as Mezzanine bus. 

[0016] Computer 130 typically includes a variety of 
computer readable media. Such media may be any 
available media that is accessible by computer 1 30, and 
it includes both volatile and non-volatile media, remov- 

20 able and non-removable media. 

[0017] In Fig. 1, system memory 134 includes com- 
puter readable media in the form of volatile memory, 
such as random access memory (RAM) 140, and/or 
non-volatile memory, such as read only memory (ROM) 

25 1 38. A basic input/output system (BIOS) 1 42, containing 
the basic routines that help to transfer information be- 
tween elements within computer 130, such as during 
start-up, is stored in ROM 138. RAM 140 typically con- 
tains data and/or program modules that are immediately 

30 accessible to and/or presently being operated on by 
processor 132. 

[0018] Computer 130 may further include other re- 
movable/non-removable, volatile/non-volatile computer 
storage media. For example. Fig. 1 illustrates a hard 

35 disk drive 144 for reading from and writing to a non-re- 
movable, non-volatile magnetic media (not shown and 
typically called a "hard drive"), a magnetic disk drive 1 46 
for reading from and writing to a removable, non-volatile 
magnetic disk 148 (e.g., a "floppy disk"), and an optical 

40 disk drive 1 50 for reading from or writing to a removable, 
non-volatile optical disk 152 such as a CD-ROM, CD-R, 
CD-RW, DVD-ROM, DVD-RAM or other optical media. 
Hard disk drive 1 44, magnetic disk drive 1 46 and optical 
disk drive 1 50 are each connected to bus 1 36 by one or 

45 more interfaces 154. 

[001 9] The drives and associated computer-readable 
media provide nonvolatile storage of computer readable 
instructions, data structures, program modules, and oth- 
er data for computer 1 30. Although the exemplary envi- 

50 ronment described herein employs a hard disk, a remov- 
able magnetic disk 148 and a removable optical disk 
152, it should be appreciated by those skilled in the art 
that other types of computer readable media which can 
store data that is accessible by a computer, such as 

55 magnetic cassettes, flash memory cards, digital video 
disks, random access memories (RAMs), read only 
memories (ROM), and the like, may also be used in the 
exemplary operating environment. 
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[0020] A number of program modules may be stored 
on the hard disk, magnetic disl< 148, optical disk 152, 
ROM 1 38, or RAM 1 40, including, e.g. , an operating sys- 
tem 158, one or more application programs 160, other 
program modules 162, and program data 164. 
[0021] The improved methods and systems de- 
scribed herein may be implemented within operating 
system 1 58, one or more application programs 1 60, oth- 
er program modules 162, and/or program data 164. 
[0022] A user may provide commands and informa- 
tion into computer 130 through input devices such as 
keyboard 166 and pointing device 168 (such as a 
"mouse"). Other input devices (not shown) may include 
a microphone, joystick, game pad, satellite dish, serial 
port, scanner, camera, etc. These and other input de- 
vices are connected to the processing unit 132 through 
a user input interface 1 70 that is coupled to bus 1 36, but 
may be connected by other interface and bus structures, 
such as a parallel port, game port, or a universal serial 
bus (USB). 

[0023] A monitor 1 72 or other type of display device 
is also connected to bus 136 via an interface, such as 
a video adapter 1 74. In addition to monitor 1 72, personal 
computers typically include other peripheral output de- 
vices (not shown), such as speakers and printers, which 
may be connected through output peripheral interface 
175. 

[0024] Computer 1 30 may operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computer 182. Re- 
mote computer 1 82 may include many or all of the ele- 
ments and features described herein relative to compu- 
ter 130. 

[0025] Logical connections shown in Fig. 1 are a local 
area network (LAN) 177 and a general wide area net- 
work (WAN) 179. Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, intranets, and the Internet. 
[0026] When used in a LAN networking environment, 
computer 130 is connected to LAN 177 via network in- 
terface or adapter 186. When used in a WAN networking 
environment, the computer typically includes a modem 
178 or other means for establishing communications 
over WAN 179. Modem 178, which may be internal or 
external, may be connected to system bus 136 via the 
user input interface 170 or other appropriate mecha- 
nism. 

[0027] Depicted in Fig. 1 , is a specific implementation 
of a WAN via the Internet. Here, computer 130 employs 
modem 178 to establish communications with at least 
one remote computer 1 82 via the Internet 1 80. 
[0028] In a networked environment, program modules 
depicted relative to computer 130, or portions thereof, 
may be stored in a remote memory storage device. 
Thus, e.g., as depicted in Fig. 1 , remote application pro- 
grams 1 89 may reside on a memory device of remote 
computer 182. It will be appreciated that the network 
connections shown and described are exemplary and 



other means of establishing a communications link be- 
tween the computers may be used. 
[0029] This description will now focus on certain as- 
pects of the present invention for controlling the scope 

5 of delegation of authentication credentials in a client- 
server network environment. While the following de- 
scription focuses on exemplary Kerberos-based sys- 
tems and improvements there to, the various methods 
and systems of the present invention are also clearly 

10 applicable to other authentication systems and tech- 
niques. For example, certificate-based authentication 
systems and techniques may adapt certain aspects of 
the present invention. 

[0030] As mentioned above, having possession of a 

15 client's ticket granting ticket (TGT) and associated au- 
thenticator allows the holder to request tickets on behalf 
of the client from the trusted third-party, e.g., a key dis- 
tribution center (KDG). Such unconstrained delegation 
is currently supported in certain implementations of Ker- 

20 beros that have forwarded ticket delegation schemes. 
[0031] With this in mind, methods and systems are 
provided to constrain or otherwise better control the del- 
egation process. The methods and systems can be 
used with different authentication protocols. The dele- 

25 gation process is controlled in certain exemplary imple- 
mentations through a service-for-user-to-proxy 
(S4U2proxy) technique. The S4U2proxy technique is 
preferably implemented as a protocol that allows a serv- 
er or service, such as, e.g., a front-end server/service, 

30 to request service tickets on behalf of a client for use 
with other servers/services. As described in greater de- 
tail below, the S4U2proxy protocol advantageously pro- 
vides for constrained delegation in a controllable man- 
ner that does not require the client to forward a TGT to 

35 the front-end server. 

[0032] Another technique provided herein is a serv- 
ice-for-user-to-self (S4U2self) technique. The S4U2self 
technique or protocol allows a server to request a serv- 
ice ticket to itself, but with the client's identity being pro- 

40 vided in the resulting service ticket. This allows, for ex- 
ample, a client, which has been authenticated by other 
authentication protocols, to essentially have a service 
ticket that can then be used with the S4U2proxy protocol 
to provide constrained delegation. There are two exem- 

45 piary forms to the S4U2self technique, namely a "no ev- 
idence" form and an "evidence" form. In the no evidence 
form, the server is trusted to authenticate the client, for 
example, using another security/authentication mecha- 
nism that is private to the server, for example. In the ev- 

50 idence form, the KDG (or a trusted-third-party) makes 
the authentication based on information (evidence) pro- 
vided about the client obtained when the client authen- 
ticated to the server. 

[0033] With the methods and systems provided here- 
55 in, a client may access servers/services within a Ker- 
beros environment regardless as to whether the client 
has been authenticated by Kerberos or some other au- 
thentication protocol. Consequently, back-end and/or 
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other servers/services can be operated in an essentially 
Kerberos only environnnent. 

[0034] Reference is now nnade to the block diagram 
in Fig. 2, which depicts an S4U2proxy protocol/process 

within a client-server environnnent 200, in accordance 
with certain exemplary implementations of the present 
invention. 

[0035] As shown, a client 202 Is operatlvely coupled 
to a trusted third-party 204 having operatively config- 
ured therein an authentication service 206, e.g. , a KDC, 
a certificate granting authority, a domain controller, and 
the like. Authentication service 206 is configured to ac- 
cess information maintained in a database 208. Client 
202 and trusted third-party 204 are further operatively 
coupled to a server, namely server A 21 0. Note, as used 
herein, the terms server and service are used intermix- 
able to represent the same or similar functionality. 
[0036] In this example, server A 210 is a front-end 
server to a plurality of other servers. Thus, as depicted, 
server A 21 0 is operatively coupled to server B 21 2 and 
server C 21 4. As illustrated, server B 21 2 may be a rep- 
licated service. Also, server C 21 4 is further operatively 
coupled to a server D 21 6. 

[0037] In response to a user logging on at client 202, 
an authentication request (AS_REQ) message 220 is 
sent to authentication service 206, which responds with 
an authentication reply (AS_REP) message 222. Within 
AS_REP message 222, is a TGT associated with the 
user/client. The same or similar procedure (not illustrat- 
ed) is followed to authenticate server A 210. 
[0038] When client 202 wants to access server A 21 0, 
the client sends a ticket granting service request 
(TGS_REQ) message 224 to authentication service 
206, which returns a ticket granting service reply 
(TGS_REP) message 226. TGS_REP message 226 in- 
cludes a service ticket associated with client 202 and 
server A 21 0. Subsequently, to initiate a communication 
session, client 202 forwards the service ticket to server 
A 210, in an application protocol request (AP_REQ) 
message 228. Such processes/procedures are well 
known, and as such are not disclosed herein in greater 
detail. 

[0039] In the past, to support delegation, the client 
would need to provide server A 21 0 with the client's TGT 
to allow server A 21 0 to request additional service tick- 
ets on behalf of client 202. This is no longer necessary. 
Instead, when server A 210 needs to access another 
serveron behalf of client 202, for example, serverC214, 
then server A 21 0 and authentication service 206 oper- 
ate according to the S4U2proxy protocol. 
[0040] Thus, by way of example, in accordance with 
certain exemplary S4U2proxy protocol implementa- 
tions, server A 21 0 sends a TGS_REQ message 230 to 
authentication service 206. TGS_REQ message 230 in- 
cludes the TGT for server A 21 0 and the service ticket 
received from client 202, and identifies the desired or 
targeted server/service to which client 202 is seeking 
access, e.g., server C 214. In Kerberos, for example, 



there is a defined extensible data field, which is typically 
referred to as the "additional tickets" field. This addition- 
al tickets field can be used in the S4U2proxy protocol to 
carry the service ticket received from client 202, and a 
5 KDC options field can include a flag or other indicator 
that instructs the receiving KDC to look in the additional 
tickets field for a ticket to be used to supply a client iden- 
tity. Those skilled in the art will recognize that these or 
other fields and/or data structures can be used to carry 
the necessary information to authentication service 206. 
[0041] In processing TGS_REQ 230, authentication 
service 206 determines if client 202 has authorized del- 
egation, for example, based on the value of a "forward- 
able flag" established by client 202. Thus, delegation 
per client is enforced by the presence of the forwardable 
flag in the client's service ticket. If client 202 does not 
want to participate in delegation, then the ticket is not 
flagged as forwardable. Authentication service 206 will 
honor this flag as a client initiated restriction. 
[0042] In other implementations, authentication serv- 
ice 206 may access additional information in database 
208 that defines selected services that server A 21 0 is 
allowed to delegate to (or not delegate to) with respect 
to client 202. 

[0043] If authentication service 206 determines that 

server A 21 0 is allowed to delegate to the targeted serv- 
er/service, then a TGS_REP message 232 is sent to 
server A 21 0. TGS_REP message 232 includes a serv- 
ice ticket for the targeted server/service. This service 
ticket appears as if client 202 requested it directly from 
authentication service 206, for example, using the cli- 
ent's TGT. However, this was not done. Instead, authen- 
tication service 206 accessed the similar/necessary cli- 
ent information in database 208 after being satisfied that 
the authenticated client is essentially involved in the re- 
quest based on the service ticket that authenticated 
server A 210 received from client 202 and included in 
TGS_REQ message 230. However, since the client in- 
formation is carried in the client's ticket, the server only 
needs to copy the data from the ticket. Thus, database 
208 can be used, but copying the data in the ticket tends 
to be more efficient. 

[0044] In certain implementations, for example, 
TGS_REP message 232 identifies the targeted server/ 
service and client 202, and further includes implemen- 
tation-specific identity/user/client account data, e.g., in 
the form of a privilege attribute certificate (PAC), a se- 
curity identifier, a Unix ID, Passport ID, a certificate, etc.. 
A PAC, for example, may be generated by authentica- 
tion service 206, or simply copied from the client's serv- 
ice ticket that was included in TGS_REQ message 230. 
[0045] PAC or other user/client account data may also 
be configured to include information relating to the 
scope of delegation. Thus, for example, attention is 
drawn to Fig. 4, which is an illustrative diagram depicting 
selected portions of a Kerberos message 400 having a 
header 402 and a PAC 404. Here, PAC 404 includes 
delegation information 406. As illustrated, delegation in- 
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formation 406 includes compound identity information 
408 and access restriction information 410. 
[0046] Compound identity information 408 may, for 
example, include recorded information about the dele- 
gation process, sucli as, e.g., an indication regarding 
the fact that server A 210 requested the service ticket 
on behalf of user/client 202. Here, a plurality of such re- 
corded information may be provided that can be used 
to string together or otherwise identify the history over 
multiple delegation processes. Such information may be 
useful for auditing purposes and/or access control pur- 
poses. 

[0047] Access restriction information 410 may be 
used, for example, in conjunction with an access control 
mechanism to selectively allow access to certain serv- 
ers/services provided that client 202 has either directly 
or indirectly through server A 21 0 sought to access the 
serer/service, but not if the server/service is being indi- 
rectly sought through server B 212. This feature adds 
additional control over the delegation of authentication 
credentials. 

[0048] In the above examples client 202 was authen- 
ticated by authentication service 206. However, it is rec- 
ognized that other clients may not be so authenticated. 
An example of such a situation is depicted in Fig. 3A. 
Here, a client 302 has been authenticated using a dif- 
ferent authentication protocol mechanism 303. For ex- 
ample, authentication protocol mechanism 303 may in- 
clude Passport, secure sockets layer (SSL), NTLM, Di- 
gest, or other like authenticating protocols/procedures. 
Here, in this example, it is assumed that client 302 
chooses to access a targeted service, wh ich just so hap- 
pens to be provided by server C 214 . This choice can 
be satisfied using the above-described S4U2proxy pro- 
tocol, but only after server A 210 has completed/fol- 
lowed an S4U2self protocol/procedure. 
[0049] One basic premise with the S4U2self protocol 
is that the server, e.g., server A 210, is able to request 
a service ticket to itself for any user/client that is access- 
ing the server and which the server has itself authenti- 
cated. The exemplary S4U2self protocol described 
herein is configured to support clients that have authen- 
ticating "evidence" and clients that do not have such au- 
thenticating evidence. 

[0050] In the absence of authentication evidence that 
can be evaluated by authentication service 206, server 
A 210 will need to come to "trust" client 302. Thus, for 
example, if client 302 has an authentication certificate 
or like mechanism 304 that server A 21 0 is able to val- 
idate, then the client 302 may be determined to be "trust- 
ed". Here, client 302 is essentially being authenticated 
by server A 21 0. Next, server A 21 0 sends a TGS_REQ 
message 306 to authentication service 206 requesting 
a service ticket to itself for client 302. In response, au- 
thentication service 206 generates a TGS_REP mes- 
sage 308 that includes the requested service ticket. The 
received service ticket is then used in a subsequent 
S4U2proxy protocol/procedure to request a service tick- 



et to server C 21 4 for client 302. In certain Kerberos im- 
plementations, for example, this requires that a forward- 
able flag in the TGS_REP message 308 be set to allow 
forwarding of the service ticket. The trusted third-party 

5 may also build a PAC for client 302, which can then be 
included in the resulting service ticket 
[0051 ] If evidence of the authentication does exist for 
a client 302', then server A 210 can include such evi- 
dence in a TGS_REQ message 312 as additional pre- 

10 authentication data. This is illustratively depicted in en- 
vironment 300' in Fig. 3B. Here, evidence information 
31 0 is provided by client 302' to server A 21 0. Evidence 
information 31 0 may include, for example, a challenge/ 
response dialog, or other, information generated by an- 

f5 other "trusted" entity. Upon receipt of evidence informa- 
tion 31 0 and subsequent validation, authentication serv- 
ice 206 will grant the requested service ticket to server 
A 210 itself. It is noted, that in certain implementations, 
with the use of evidence it may be possible for the server 

20 to obtain a restricted TGT for the client. 

[0052] In certain Kerberos implementations, the for- 
wardable flag in the TGS_REP message 314 will be set 
to allow forwarding of the service ticket. If a PAC was 
provided in TGS_REQ message 312, then it can be 

25 used in the service ticket, otherwise, a PAC may be gen- 
erated by authentication service 206 (here, a KDC) 
based on evidence information 310. For example, in 
S4U2self , the identity of the client is included in the pre- 
authentication data. This identity can be used in the con- 

30 struction of the PAC for that client and added to the is- 
sued service ticket to the server (for the client). 
[0053] Although some preferred implementations of 
the various methods and systems of the present inven- 
tion have been illustrated in the accompanying Draw- 

35 ings and described in the foregoing Detailed Descrip- 
tion, it will be understood that the invention is not limited 
to the exemplary embodiments disclosed, but is capable 
of numerous rearrangements, modifications and substi- 
tutions without departing from the spirit of the invention 

40 as set forth and defined by the following claims. 



Claims 

45 1. A method comprising: 

identifying a target service to which access is 

sought on behalf of a client; 

causing a server operatively coupled to the cli- 

50 ent to request access to the target service on 

behalf of the client, from a trusted third-party, 
wherein the server provides the trusted third- 
party with a credential authenticating the serv- 
er, information about the target service, and a 

55 service credential previously provided by the 

client to the server. 

2. The method as recited in Claim 1 , wherein the trust- 
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ed third-party includes at least one service selected 
from a group of services connprising a key distribu- 
tion center (KDC) service, a certificate granting au- 
thority service, and a donnain controller service. 

3. The nnethod as recited in Claim 2, wherein the trust- 
ed third-party provides the server with a new service 
credential granted in the name of the client rather 
than the server. 

4. The method as recited in Claim 3, wherein the new 
service credential is configured for use by the server 
and the target service to which access is sought. 

5. The method as recited in Claim 3, wherein the cre- 
dential authenticating the server is a ticket that in- 
cludes a ticket granting ticket associated with the 
server. 

6. The method as recited in Claim 1 , further compris- 
ing: 

causing the trusted third-party to verify that the 
client has authorized delegation. 

7. The method as recited in Claim 6, wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); and 

causing the trusted third-party to verify that the 
client has authorized delegation includes veri- 
fying the status of a restriction placed on the 
ticket originating from the client. 

8. The method as recited in Claim 1 , further compris- 
ing: 

causing the trusted-third-party to selectively 

determine if the client is allowed to participate 
in delegation either based on information se- 
lected from a group comprising an identity of 
the client, a group affiliation associated with the 
client. 



11. The method as recited in Claim 1 , wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); and 
5 the server requests the new credential in a tick- 

et granting service request message that in- 
cludes a service ticket provided by the client to 
the server. 

10 12. A method comprising: 

identifying a target service to which access is 

sought on behalf of a client; and 

causing a server operatively coupled to the cli- 

15 ent to request access to the target service on 

behalf of the client, from a trusted third party, 
wherein the server provides the trusted third 
party with a service credential authenticating 
the server, information about the target service, 

20 and a service credential previously provided by 

the client for the service, and wherein the client 
ticket includes implementation-specific identity 
infomnation. 

25 13. The method as recited in Claim 12, wherein the im- 
plementation-specific identity information includes 
information selected from a group comprising priv- 
ilege attribute certificate (PAC) information, security 
identifier infomnation, Unix identifier information, 

30 Passport identifier information, certificate informa- 
tion. 

1 4. The method as recited in Claim 1 3, wherein the PAC 
information includes compound identity informa- 

35 tion. 

1 5. The method as recited in Claim 1 3, wherein the PAC 
information includes access control restrictions for 
use as delegation constraints. 

40 

16. A computer-readable medium having computer-ex- 
ecutable instructions for performing tasks compris- 
ing: 



9. The method as recited in Claim 1 , wherein the serv- ^5 
er is a front-end server with respect to a back-end 
server that is coupled to the front-end server, and 
wherein the back-end server is configured to pro- 
vide the target service to which access is sought. 

50 

10. The method as recited in Claim 1 , wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); 

the KDC provides a ticket-granting-ticket asso- 55 
dated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 



in a server, determining a target service to 
which access is sought on behalf of a client cou- 
pled to the server; 

requesting a new service credential from a 
trusted third-party by providing the trusted 
third-party with a credential authenticating the 
server, information about the target service, 
and a service credential associated with the cli- 
ent and the requesting server. 

17. The computer-readable medium as recited in Claim 
1 6, wherein the trusted third-party includes at least 
one service selected from a group of services com- 
prising a key distribution center (KDC) service, a 
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certificate granting autfiority service, and a domain 
controller service. 

18. The computer-readable medium as recited in Claim 

1 7, wlierein tine new service credential is granted in 
tlie name of tlie client rather than the server. 

19. The computer-readable medium as recited in Claim 

1 8, wherein the service credential is configured for 
use by the server and the target service. 

20. The computer-readable medium as recited in Claim 

1 8, wherein the credential authenticating the server 
includes a ticket granting ticket associated with the 
server. 

21 . The computer-readable medium as recited in Claim 
16, further comprising: 

causing the trusted third-party to verify that the 
client has authorized delegation. 

22. The computer-readable medium as recited in Claim 
21 , wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); and 

causing the trusted third-party to verify that the 
client has authorized delegation includes veri- 
fying the status of a forwardable flag value as 
set by the client.. 

23. The computer-readable medium as recited in Claim 
1 6, wherein the server is a front-end server with re- 
spect to a back-end server coupled to the front-end 
server, and wherein the back-end server is config- 
ured to provide the target service. 

24. The computer-readable medium as recited in Claim 
16, wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); 

the KDC provides a ticket-granting-ticket asso- 
ciated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 

25. The computer-readable medium as recited in Claim 
16, wherein: 

the trusted third-party includes a key distribu- 
tion center (KDC); and 

the requesting server requests the new service 
credential in a ticket granting service request 
message that includes a service ticket provided 
by the client to the server. 



26. A system comprising: 

a credential granting mechanism configured to 
receive a request for a new service credential 

5 from a server and in response generate the new 

service credential if delegation is allowable, 
and wherein the request includes: 

a credential authenticating the requesting 

10 server, 

identifying information about a target serv- 
ice to which access is sought on behalf of 
a client coupled to the server, and 
a service credential that was previously 

15 granted to the client for use with the server. 

27. The system as recited in Claim 26, wherein the cre- 
dential granting mechanism is provided by a trusted 
third party and includes at least one service select- 

20 ed from a group of services comprising a key distri- 
bution center (KDC) service, a certificate granting 
authority service, and a domain controller service. 

28. The system as recited in Claim 27, wherein the new 
25 service credential is granted in the name of the cli- 
ent rather than the server. 

29. The system as recited in Claim 28, wherein the 
service credential is conf igu red for use by the server 

30 and the target service. 

30. The system as recited in Claim 28, wherein the cre- 
dential authenticating the server includes a ticket 
granting ticket associated with the server, and 

35 which was previously granted by the credential 
granting mechanism. 

31 . A system comprising: 

40 a server configured to generate a request for a 

new service credential from a trusted third-par- 
ty, the new service credential being associated 
with a client and a target service, the request 
comprising: 

45 

a credential authenticating the server, 
information about the target service, and 
a service credential associated with the cli- 
ent and the server. 

50 

32. The system as recited in Claim 31, wherein the 
trusted third-party includes at least one service se- 
lected from a group of services comprising a key 
distribution center (KDC) service, a certificate 

55 granting authority service, and a. domain controller 
service. 

33. The system as recited in Claim 31 , wherein the cre- 
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dential authenticating the server includes a ticket 
granting ticket associated with the server. 

34. The system as recited in Clainn 31, wherein the 
server is a front-end server with respect to the serv- 
ice. 

35. The system as recited in Claim 31, wherein the 
server requests the new service credential in a tick- 
et granting service request message that includes 
the service ticket associated with the client and the 
server. 

36. A computer-readable medium having stored there- 
on a data structure, comprising: 

a credential authenticating a first server, 
information identifying a second server, and 
a service credential associated with a client and 
the first server. 

37. The computer-readable medium as recited in Claim 
36, wherein the credential authenticating the first 
server includes a ticket-granting-ticket (TGT) and 
the service credential includes a service ticket. 

38. A method comprising: 

separately authenticating a server and a client; 
providing the server with a server ticket grant- 
ing ticket; 

providing the client with a client ticket granting 
ticket and a service ticket for use with the serv- 
er; 

providing the server with a new service ticket 
for use by the server for use with a new service 
without requiring the server to have access to 
the client ticket granting ticket. 

39. The method as recited in Claim 38, further compris- 
ing: 

causing the server to request the new service 
ticket on behalf of the client by forwarding the 
server ticket granting ticket, information identi- 
fying the new service, and the service ticket to 
a trusted third party. 

40. A method comprising: 

identifying a target service to which access is 
sought on behalf of a client that has been au- 
thenticated using a first authentication method; 
causing a server that is operatively coupled to 
the target service and the client to request a 
service credential to itself from a second au- 
thentication method trusted third-party by iden- 
tifying the client and the first authentication pro- 



tocol; and 

causing the serverto request a new service cre- 
dential, for use by the server and the target 
service, from the second authentication meth- 
5 od trusted third-party, wherein the server pro- 

vides the trusted third-party with a credential 
authenticating the server, information about the 
target service, and the service credential to it- 
self. 

10 

41 . The method as recited in Claim 40, wherein the sec- 
ond authentication method trusted third-party in- 
cludes at least one service selected from a group 
of services comprising a key distribution center 

15 (KDC) service, a certificate granting authority serv- 
ice, and a domain controller service. 

42. The method as recited in Claim 41 , wherein the new 
service credential is granted in an identity of thecli- 

20 ent rather than an identity of the server. 

43. The method as recited in Claim 42, wherein the 

service credential is conf igu red for use by the server 
and the target service to which access is sought. 

25 

44. The method as recited in Claim 42, wherein the cre- 
dential authenticating the server includes a ticket 
granting ticket associated with the server. 

30 45. The method as recited in Claim 40, further compris- 
ing: 

upon receiving a request for the new service 
credential from the server, causing the second 
35 authentication method trusted third-party to 

verify that the client has authorized delegation. 

46. The method as recited in Claim 40, wherein the 
server is a front-end server with respect to a back- 

40 end server that is coupled to the front-end server, 
and wherein the back-end server is configured to 
provide the target service. 

47. The method as recited in Claim 40, wherein the first 
45 authentication method is selected from a group of 

authentication methods comprising Passport, SSL, 
NTLM, and Digest. 

48. The method as recited in Claim 40, wherein the sec- 
50 ond authentication method includes a Kerberos au- 
thentication protocol. 

49. A computer-readable medium having computer-ex- 
ecutable instructions for performing tasks compris- 
es ing: 

identifying a target service to which access is 
sought on behalf of a client that has been au- 
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thenticated using a first autlientication metliod; 
causing a server that is operatively coupled to 
the target service and the client to request a 
service ticket to itself from a second authenti- 
cation nnethod trusted third-party by identifying 
the client and the first authentication protocol; 
and 

causing the server to request a new service 
ticket, for use by the server and the identified 

service, fronn the second authentication meth- 
od trusted third-party, wherein the server pro- 
vides the trusted third-party with a ticket au- 
thenticating the server, information about the 
target service, and the service ticket to itself. 

50. The computer-readable medium as recited in Claim 

49, wherein the second authentication method 
trusted third-party includes a key distribution center 
(KDC). 

51 . The computer-readable medium as recited in Claim 

50, wherein the new service ticket includes a serv- 
ice ticket granted in an identity of the client rather 
than an identity of the server. 

52. The computer-readable medium as recited in Claim 

51 , wherein the service ticket is configured for use 
by the server and the target service. 

53. The computer-readable medium as recited in Claim 

51 , wherein the ticket authenticating the server in- 
cludes a ticket granting ticket associated with the 
server. 

54. The computer-readable medium as recited in Claim 
49, further comprising: 

upon receiving a request for the new service 
ticket from the server, causing the second au- 
thentication method trusted third-party to verify 
that the client has authorized delegation. 

55. The computer-readable medium as recited in Claim 
49, wherein the server is a front-end server with re- 
spect to a back-end server that is coupled to the 
front-end server, and wherein the back-end server 
is configured to provide the target service. 

56. The computer-readable medium as recited in Claim 
49, wherein the first authentication method is se- 
lected from a group of authentication methods com- 
prising Passport, SSL, NTLM, and Digest. 

57. The computer-readable medium as recited in Claim 
49, wherein the second authentication method in- 
cludes a Kerberos authentication protocol. 

58. A system comprising: 



a server configurable to: 

identify a target service to which access is 
sought on behalf of a client that has been 
5 authenticated using a first authentication 

method, 

request a service credential to itself from a 
second authentication method trusted 
third-party by identifying the client and the 
10 first authentication method, and 

subsequently request a new service cre- 
dential, for use by the server and the target 
service, from the second authentication 
method trusted third-party, 

15 

wherein the server provides the second au- 
thentication method trusted third-party with a cre- 
dential authenticating the server, information about 
the target service, and the service credential to it- 
20 self. 

59. The system as recited in Claim 58, wherein the new 
service credential is granted in an identity of the cli- 
ent rather than the server. 

25 

60. The system as recited in Claim 59, wherein the new 
service credential is conf igu red for use by the server 
and the target service. 

30 61 . The system as recited in Claim 59, wherein the cre- 
dential authenticating the server includes a ticket 
granting ticket associated with the server. 

62. The system as recited in Claim 57, wherein the 
35 server is a front-end server with respect to a back- 
end server that is coupled to the front-end server, 
and wherein the back-end server is configured to 
provide the target service. 

40 63. The system as recited in Claim 57, wherein the first 
authentication method is selected from a group of 
authentication methods comprising Passport, SSL, 
NTLM, and Digest. 

45 64. The system as recited in Claim 57, wherein the sec- 
ond authentication method uses a Kerberos au- 
thentication protocol. 
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